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AMENDMENT UNDER PCX ARTICLE 34 

Dear Sir: 

This paper is. herewith filed in response to the Written Opinion dated 17 December 2004 for the 
above-identified Intemational Patent Application. The Authorized Officer has stated that claims 
1-26 lack novelty over a reference to Williams et al (US Pat. Application Publication No. 
. 2002/0133600). 

Respecting the claims, attached are replacement pages numbered 20-23 to replace pages 20-26 
of the application, and original pages 24-26 are canceled. Annotated pages showing changes to 
the claims are attached for the Authorized Officer's convenience. Respecting the drawings, 
formal drawings are hereby submitted in eight sheets, labeled as replacement pages and 
attached hereto. Respecting the specification, annotated and replacement pages are attached to 
correct spelling and grammatical errors, and to comport the "Summary*' section to the claims as 
amended herein. 
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Remarks: 

Replacement pages for the written description are . provided to correct minor errors. 
Specifically, replacement pages 2-5 and 7-19 are provided to replace pages 2-19. Original page 
6 is canceled. All paragraph numbers, beginning at para [0010], are changed to a four-digit 
form. This represents the only change to page 8. Further changes made in the remaining 
replacement pages are as follows: 

Page 2, para [0004], line 12, "so" is changed to "to"; 

Page 3, para [0004], line 2, "that the R-P interface" is changed to "for the R-P interface 

to"; 

Page 3, para [0005], line 17, "he MS" is changed to "the MS"; 

Page 4, paras [0007] and [0008] are rewritten to comport to amended claims 1 and 15; 

Page 5, paras [0009] and [0011] are deleted, and para [0010] is amended to comport to 
amended claim 23; . 

Page 7, para [0015] is amended to reflect Fig. 2 is broken into Figs. 2A-2B; 

Page 9, para [0026], Une 2, "authorize" is changed to "authorizes", and at line 5 is 
amended to reflect that Fig. 2 is represented by Figs. 2A-2B; 

Page 11, para [0031], line 10, "(SR_ID x) meets" is changed to "(SR_ID x) which 
meets"; 

Page 11, para [0032], line 5, ^request" is changed to "the request"; 
Page 12, para [0035], line 5, "Packet s" is changed to "Packets", and at line 7, "date" is 
changed to "data"; 

Page 13, para [0036], lines 3 and 5, "flow 48" is changed to "flow 62", and at line 10, 
"upon" is changed to 'TJpon"; 

Page 14, para [0037], line 4, "Ms 26" is changed to "MS 26"; 
Page 14, para [0038], line 1, "RN 30" is changed to *TRN 24"; . 

Page 15, para [0039], line 6, "of RESV" is changed to "or RESV", and at line 12, "map 
72" is changed to "map"; 

Page 16, para [0040], line 2, comma added after "well"; 

Page 16, para [0042], line 3, "message" is changed to "message 78"; and a line is added 
following para [0042] to separate it firom the following paragraph. 
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Page 17, para [0044], line 2, "90 cairies" is changed to "90 which carries"; 
Page 18, para [0046], line 2, *these teachings could" is changed to '*they could be"; 
Page 19, para [0050], line 6, "paratneter(s)" is changed to "parameter(s) apply"; and 
• Page 19, para [0051], hues 1 and 3, "MN 24" is changed to RN 24". 

Formal drawings, all of which are marked as replacement pages, are submitted to replace the 
informal drawings originally filed. Of those drawing replacernent pages. Figure 2 is now 
divided among two drawings sheets and labeled Fig. 2 A and Fig. 2B. Also, Figure 2B is 
amended as compared to the original in that the contents of the RESV message 58 now recites 
"(SR_ID, TFT, QoS REQUHIEMENT)". This draws support firom message 78 of Figure 5 A. 
No changes apart from those noted above are made to any of the replacement drawing sheets, 
and no new matter is added. 

All claims are amended to more clearly recite the invention, and to remove extraneous claim 
language. Claims 1-13, 15-19, and 23-24 are amended by claims bearing the same number, 
original claims 14, 20-22 and 25-26 are cancelled, and new claims 27-30 are added. 

These claims are seen to distinguish over the reference to WilUams in that Williams is not seen 
to disclose, as recited in claim 1, sending a second request message from a wireless network 
node that comprises one or more granted quality parameters. Because this second request 
message carries a granted quality parameter, it must be sent after the grant. It is noted that the 
quality parameter granted (and sent in the second request message) is not necessarily that 
quality parameter of the first request message. 

Claim 1 is changed to recite specific nodes that appear to lie within the UMTS network 80 of 
Williams' Fig. 6. Williams is not seen to send a request message from a wireless network node 
that includes one or more granted quality parameters as claimed, because the grant occurs in 
Williams' IMSS 82. Nodes are characterized with more specifically in claim 2, where the 
wireless network node is the radio node (such as would be disposed within Williams' radio 
access network 90) and the "fiirther node" is the packet data switching node (such as would be 
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disposed within Williams' packet access network 92, for example, the SGSN 94). Considering 
the prior art Figure 1 of the present application, Williams appears to be primarily directed to the 
IP-based external network 32 whereas the present invention is primarily directed to the mobile 
network 22 and the R-P interface, as described at paragraph [0004] of the present specification. 

As recited in paragraph [0038] of the present application, an important aspect of Figure 2 is that 
the radio node 24 derives QoS requirements from the MS26, then sends the QoS requirements 
to the PDSN 30. Deriving the QoS requirement from the MS corresponds to receiving the 
request message 44 of Fig. 2 and the first request message of claim 1. Sending the QoS 
requirements to the PDSN corresponds to sending the registration request 52 of Fig. 2 and 
sending the second request message of claim 1. The radio node does not passively relay the 
QoS message 44 from the mobile station to the PDSN, for in all cases the QoS message that it 
receives carries the requested QoS parameters, and the registration request message that it 
sends carries granted QoS parameters. The QoS message 44 from the mobile station terminates 
at the radio node, and triggers the sending of the registration request message (once QoS 
parameters between the radio node and the mobile station are granted as shown in Figure 2). 

At paragraph [0035] of WiUiams (which refers to Fig. 4), the access bearer control blocks 40, 
46 of the mobile terminal 10 and the access point 15 set up a pipe or flow. Williams explicitly 
recites that the bearer control signaling that sets up the flow move transparently through the 
radio access network. Comparing Williams' Figs 4 and 3, the access point 15 clearly cannot be 
a wireless node as recited in claim 1, because it is outside the RAN 12 and its name implies 
congruence with the packet data switching node described in the present written description 
(the fiirther node of claim 6). 

At paragraph [0052] of Williams (which refers to Fig. 10, which relates to Fig. 6 through paras. 
0027-0028), it is Williams' policy control fimction 100 that authorizes the required QoS 
resources for a session. In Fig. 10, the GGSN is clearly disposed between the initiating, mobile 
terminal UE-A and the policy control ftmction 100. The GGSN is described at paragraph 
[0016] and in Fig. 6 as serving as an access point. William's disposition of the policy control 
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function that grants the QoS resources clearly appears outside the radio access network, so 
Williams does not disclose that his policy control function may lie within a wireless node. 

For at least the above reasons, claims 1-13 and 27 are seen to be novel and non-obvious over 
Williams. 

Claim 15 recites a signaling protocol among specific nodes, of which at least those nodes 
within the radio network (the mobile station and the radio node) are specifically detailed in the 
claim. Claim 15 specifically recites that the radio node sends a graated set of QoS parameters 
to the PDSN in a registratioii request. For the same reasons detailed above, claims 15-19 and 
28 are seen to be novel and non-obvious over Williams over Williams. 

Claims 20-22, formerly to a mobile station, and claims 25-26, formerly to a packet data 
switching node, are cancelled. 

Claims 23-24 and 29-30 are directed to a wireless network node, and are seen to be novel and 
non-obvious over Williams for the same reasons as detailed above. 

The Authorized Officer is respectfiilly requested to enter the amendments made herein and to 
withdraw the objections to clarity in view of these amendments. 

Respectfully submitted. 
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Claims: 

WHAT IS CLAIMED IS: 

1 . A method for establishin g, between a first and a Gocond node, a data flow within a 
servdc e instanc e comprising: 

sending firom a mobilo station to receiving at a wireless a rfes^network node a first 
request messag e, said first r e quest m e ssage including a service instance identifier, a flow 
id e ntifi e r thnt \miq^^^^y iHftTiti'fjnr . n n^w finw nrftntnd hy the mobilo station, and comprising at 
least one quality of service p arameter for the aew flow; 

determining at the first nodo whether a new flow that satiGfies the at least ono quality 
parameter can be supported between tho first nod e and the mobile station; 

granting a plurality of quality of service parameters: 

sending fi*om the fifs ^v^eless network n ode to a second network nod e a second request 
message, the second request messag e including a service instanc e identifier and at least 
comprising one or more granted quality parametersv-and 

— authorizing at th e second nodo a servaco instance, identified by the sorvdcQ instanc e 

identifier of the second message, that satisfies the at least one quality parameter of the second 
m e ssag e. 

2. The method of claim 1 wherein the fijest wireless network n ode is a radio node and the 
second node is a packet data switching node . 

3 . The method of claim 1 , wherein detemmiing at the fiurst nod e compris e s fiir^^ 
comprising : 

d e termining that a pr e existing sorvico instance, id e ntified by th e service instance 
identifier of th e first request message, can support the new flow and its associated at l e ast one 
quality parameter betvv^een the first node and the mobile station; and 

sending firom the first wireless network n ode to fee a_mobile station a reply message, 
said reply message including the service instance identifier of the first r e quest messag e , the 
flow identifier, and th o at least one t he granted plurality of quality of service p aramete rs and 
airlink parameters for the new flowj 
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wherein the service instano e id e ntifier of th e first and Gocond request mossagoo is the 

snxne. 

4. The method of claim 4r 3, wherein determining at tho first node compriseo: 
dotermining that a pre existing servic e instance, identified by th e scrvico instance 

identifier of the first request message, cannot support the new flow and it's associated at l e ast 
on e quality paranaeter between the first node and th e mobile station; 

determining that tho now flow is to bo \^ithin a new service instance that supports the at 

least on e quality param e ter; and 

sending firom the first node to the mobilo station a reply m e ssag e , said rqply message 

including further includes a new service instanc e flow i dentifier that uniquely identifies the 
new s e rvice instance to th e mobile station, th e flow identifier, and the at least one quality 
parameter for the new flow; 

whorein th e service instance identifi e r of the second r e qu e st message is the now service 

instance identifier . 

5 . The method of claim + 2 further comprising receiving w herein the second node r e ceives . 
firom a node other than the &st wireless network n ode and tibe a,mobile station that originates 
the first request niessage, prior to th e sending of th e first request messag e , a subscriber profile 
that includes a plurahty series of quality parameters associated with the mobile station, 

6. The method of claim 4-2, fiuiher comprising: 

sending firom ^ a_mobile statio n that originates the first request message to the second 
netw^orlc a further node a filter message, said filter message including th e flow identifier, a flow 
direction for th e new flow, and at least one packet filter. 

7. The method of claim 6, wherein the at least one packet filter comprises a plurality of 
packet fi4tef s filter content options, and the at least one packet filter is identified by a flow 
identifier that uniquely identify the new flow over all other flows associat e d with the mobil e 
station . 
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8. The method of claim 6-2 further comprising: 

following Gcnding tho filter message, determining at the first wireless network n ode that 
the aew flow cannot be further supported to meet the at least one plurality of q uality of service 
parameters of the s e cond messag e that were granted : 

sending from the first node to th e second node a modified second request message^^ 
modified second message including the servico inotanco identifier of the second request 
messag e and that includes at least one updated quaUty of service p arameter that differs from the 
at least one qualit>^ param e ters of the s e cond message ; and 

receiving authorizi agation at th e second nod e tho servaco instance, id e ntified by th e 
ser\ac e instanc e identifier of tho second r e quest mossag e .t o satisfy the at least one updated 
quality of service p arameter. 

9. The method of claim 6- 8, wherein the modified second request message includes an 
identifier for further comprising, at one of th e first or second nodes, mapping the ser\ace 
instance identifier of tho second r e quest message to at least on e of the flow identifier and the at 
least on e packet filter . 

10. The method of claim 1 further comprising: 

determining a policy to apply to ftte apacket transported on the flow , and mapping fee 
an service instanc e identifie r associated with the flow to the policy. 

11.. The method of claim 1 0, wherein determining a policy is at the second a further node, 
and the method further comprising enforcing t he policy is enforc e d at the second further node 
on the packet sent in at least one of an uplink and a downlink direction. 

12. The method of claim 10 wherein deteraiining a policy is at the first wireless network 
node, and the method further comprising enforcing the policy if enforced at the first wireless 
network node for the packet sent at least in an uplink direction firom the first to the second 
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further node. 



13. The method of claim 10 wherein determining a pohcy is at the second further node, aad 
the method further comprising enforcing the poUcy is enforced at the fest wireless network 
node at least for the packet sent in an uplink direction from the &st wireless network node t o 
the second further node. 

44; The method of claim 1 further comprising, after authorizing at th e second node a 

service instance, s e nding from tti e second node to the first node a registration reply message 
that informs th e first nod e of th e authorization. 

15. A signaling protocol to enable an assured quality on at least one of several a.flows ef^ 
servic e instance between a radio node and a packet switching data node, comprising: 

e stablishing a main Ger\ic e instanc e betwe e n a mobile station and a radio node; 

th e mobile station signaling th e a_radio node station with a servdce instance identifier, a 
new flow identifier, and receiving from a mobile station a request that includes at least one 
quality of service p arameter for the Hew flow identified by th e flow identifi e r ; 

subsequ e nt to the radio nod e d e termining a candidate servic e instance that can carry the 
flow so as to satisfy the at least on e quality parameter, th e candidate ser\doo instance being on e 
of a pre existing and a n e w s e rvice instance, the radio node signaling sending to the mobile 
station and a packet data switching node with the candidat e service instanc e identifier; a^gnt 
of a set of quality of service parameters for the flow; 

the radio node further sending a registration request to a packet data switching node that 

includes the granted set of quality parameters for the flow: and 

the radio node receiving from t he packet data switching node signaling the radio node 
wi^ a registration reply that authorizes the flow an authorization that includes the candidate 
servic e instance identifier; 

■ — the mobile station signaling at l e ast one of the radio node and the packet data switching 

node via the radio node with packet filters that uniquely identify th e new flow; and 
sending a data packet between the radio and packet data smtohing nodes on the new 



10 



( f 

Int'l Application No. PCT/US04/25398 

Art. 34 Amendment dated Febmary 16, 2005 

Annotated Claims 

flow basod on tho pack e t filters . 

1 6. The signaling protocol of claim 4428 wherein the mobile station signaling sending a 
filter message to at least one of the radio node and the packet data switching node via tho radio 
node compriGOG signaling with packet filtorG, flow direction, and the flow identifiert hat 
comprises at least one packet filter for the flow . 

17. The signaling protocol of claim 4#28 fiirther comprising signaling firom an AAA node 
te receiving at t he packet switching data node firom an AAA node a series of quality of service 
parameters associated with the mobile station. 

18. The signaling protocol of claim 15, wherein the radio nod e signaling the mobile station 
and a packet data swdtching node with tho candidate s e rvic e instance identifier fiirther 
nnmpn>, n r. thR rndin nodo nignaling th e mobile station the grant comprises , in a single signaling 
message, the_oandidato service instance an identifie r and parameters to establish a now traffic 
airifel efor the flow . 

19. The signaling protocol of claim 1 5 wherein the mobile station signaling tho radio station 
with rrequest comprises, in a. single message, a gorvice instanc e , an identifie r for the anew flow 
identifier, and at least on e quality parameter for tho now flow identifi e d by th e flow identifier 
comprises signaling in a singl e message . 

SOi A mobile station comprising: 

a controller for determining that data, to be transferred b e tween the mobil e station and a 

mobile node coupled to the mobil e station via an airlinlc, is one of a first or second data t>pe; 

a memory that stores an application program,'' said application program comprising an 

association of a first data type with a first set of at least one transport quah^y parameters and an 
association of a different second data t>po with a different second sot of at least one transport 
quality parameters, 

the apphcation program fiirther comprising computer instructions to construct a QoS 
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parameter request message that includeG a ser\dce instance identifier and tho first or Gocond set 
of at least on e transport quality parameters associated with the data t>po determined by the 
controller; and 

a transmitter coupled b e tween the controller and an antenna, for transmitting tho QoS 

parameter request message to th e mobile node. 

2ir-. The mobil e station of claim 20 fiirtfa e r comprising a r e coiver couplod between th e 

antenna and th e controller for receiving a service oomect message that includes a serv'ice 
instance identifier and th e set of at least ono transport quality parameters associated with the 
data type determined by the controller, 

wherein die apphcation program is fiirther for constructing, in response to recei\dng the 

servic e coimect mess ago, a filter message that comprises a set of at least on e filter parameters 
and an identifier for a servic e instance into which data paclcots filtered by th e set of at least one 
filt e r parameters are filtered into. 

23r. The mobil e station of claim 21 wherein tho identifier for a servdco inotanco is a flow 

identifier that uniquely identifies a flow_carried on the ser\dce instanc e into which data packets 
filtered by the set of at l e ast on e filter paramet e rs are filt e red into. 

23 . A bas e statio nw ireless network node comprising: 

a receiver for receivrri g, from a mobilo station coupled to the bas e station via an airlink, 
a QoS parameter request message that includes at least an existing sorvdc e instance identifier 
and a s e t of at least one quality of service p arameters -for a flow ; 

a controller coupled to the receiver for determining and granting wh e ther a s ubject 
ser\'^ice instance, on which a now flow satisfying the set of at least one quality of service 
piaramete rs b e tween at least the bas e station and th e mobile station, is a pre existing servdce 
instance or a new service instance ; and 

a transmitter coupled to the controller for sending, in response to the controller 
determiixing and granting, a servic e coimect reply m essage to the mobile statio n and a 
registration r e qu e st message to a packet data switching nod e , each of said messages comprising 
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a service instaQce identifier for th e subject servico inotance . 

24. The base station wireless network node of claim 23-30, wherein the registration request 
message further comprises the set of at least one quahty of service p arameters. 

OS-. A packet data switching node comprising: 

a r e ceiver for recei\dng firom a base station a registration r e quest message and a filt e r 

message, said registration request messag e comprising a service instanc e id e ntifier and a set of 
at least one qualit>^ parameters, and the filter message comprising a sot of at least one packet 
filters; 

a controller for determining that a subject service instance identified by the s e rvdce 

instance identifier may satisfy the set of at l e ast one quality parameters, and for routing data 
packets that satisfy each of the set of packet filters along the subject sorvico instance; and 

a transmittor for sending an authorization message to the base station in respons e to the 

controller so detemiining. 

36i Th e packet data switching node of claim 25 wherein filter message further comprises a 

flow identifier, and the controller is for routing data packets that satisfy each of th e set of 
packet filters along a data flow identified by the flow identifier, said data flow being wdthin th e 
subject servic e instance. 

27. The method of claim 2 wherein the further node is a packet data switching node. 

28. The signaling protocol of claim 15, further comprising: 

the mobile station signaling the packet data switching node via the radio node with 

packet filters that identify the flow. 

29. The wireless network node of claim 23, wherein the transmitter is further for sending a 
registration request message to a packet data switching node. 
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30. The wireless network node of claim 29. wherein the registra tion request message 
comprises an identifier for the flow. 
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[0003] The present invention relates to DiflEServ, of which the general architecture is 

based on the general concept that traffic (e.g., data packets) entering a network is classified 
and possibly conditioned (e.g., marked, metered, policed, shaped) at tiie boundaries or 'edge 
routers' of the data pathway through the network, and assigned to different behavior 
aggregates. Each behavior aggregate is idratified.by a single Differentiated Services Code 
Point (DSCP), which is a bit stream in the header of each packet (currently, 6 bits). Within 
the core of the network (internal nodes not at the 'edge' of a data pathway), packets are 
forwarded according to a "per-hop" behavior PHB associated with the DSCP. Per-hop 
behavior represents thresholds within which the packet moves among network nodes; for 
example, bounds for delay, jitter, bandwidth, etc., and are used for allocating buffer and 
bandwidth resources at each node among competing traffic streams. Well-defined PHB is 
used with packet markings to achieve a scalable QoS solution for any given packet. In 
DiffServ then, signaling for QoS is eliminated at least within the network core, so the number 
of packet states required to be kept at each network node is reduced considerably. For 
example, the intemal routers or nodes need not track per-application flow or per-customer 
forwarding states for transient packets. The end result is that complexity is pushed to the edge 
of the network in DiffServ to keep the (typically more numeroxis) core routers or nodes simple 
and fast. 

[0004] The edge routers in a DiffServ domain are also termed ingress or egress nodes, 

depending on the traffic direction. Figure 1 depicts a prior art overview of a 
CDMA2000/3GPP2 combined network 20 in which a DiffServ architecture might be used. A 
mobile network 22, such as one employing 3GPP2 protocols, includes a radio node RN 24 
(e.g., a base station BS) that s'erves as the ingress node for uplink traffic fi:om a mobile station 
MS 26 under control of that RN 24. A first message 28 firom the MS passes through the RN 
24 and to a packet data switching node (PDSN) 30. Once leaving the PDSN 30, the packet 
must carry attributes that will allow routers and other nodes within the CDMA2000 network 
32 to convey that packet with a certain quality without each having to *open' the packet and 
independently determine the appropriate pathway necessary to satisfy the desired quality. For 
a second message 34 from the IP-based network 32 to the MS 26, the PDSN 30 serves as the 
egress node. The means (e.g., per hop behavior) used by the IP-based network 32 to meet a 
quality criteria is generally not directly adaptable to the mobile network 22. The interface 
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between the RN 24 and the PDSN 30 is generally temed the R-P network or R-P interface. 
There are currently broad concepts for the R-P to interface operate to facilitate DifEServ 
among the broader 32 and mobile 22 networks, but no specific details as to how such 
functionality might be implemented are known to the inventors except for downlink traffic on 
a service instance carrying one flow, described below. 

[0005] In the current 3GPP2 standardization [3GPP2 P.SOOOl C.4], flow mapping and 

treatment is introduced to map a particular downlink flow to a service instance. A main 
service instance represents one R-P connection and is identified by a unique identifier 
(SR_ID) carried in initializing the R-P coimection. As described in 3GPP2 specification 
[3GPP2 X.S001 1-004-C, ver. 1.0, August 2003; sections 3 and 3.2 et seq.], in addition to a 
main service instance, a MN 26 may open one or more auxiliary service instances, on the 
same or a different R-P connection as the main service instance, to cany trafiSc that is not 
suitable for the main service instance. Typically, the main service instance is used to carry 
signaling that initializes and updates a connection between the MS 26 and the PDSN 30, and 
different auxiliary service instances associated with the main are used to carry the different 
types of data (e.g., streaming video, email). A (preferably auxiliary) service instance may 
carry multiple flows, a 'flow being a specific instantiation of a protocol layer sequence through 
which packets on that flow are transported. In order to effectively use the auxiliary service 
instance, the PDSN 30 needs to be informed about packet filters. Packet filters are 
information that the PDSN 30 uses to map which packet is to be sent on which service 
instance. A Traffic Flow Template TFT, sent by the MS to support one service instance, 
carries the MS IP address (which may change as the MS 26 moves between home and foreign 
networks) and packet filter components, such as but not limited to packet destination IP 
address and port number, protocol type, and type of service. One TFT corresponds to one 
service instance (identified by SR_ID), allowing the PDSN 30 to put packets of different 
types into different auxiliary service instances. 

[0006] The flow mapping mechanism described above appears capable of mapping 

only a downlink packet to a particular auxiliary service instance. Further, because it maps a 
downlink packet only to a service instance without describing how a particular flow on that 
service instance might be distinguished, it appears operable only when all flows on that 
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service instance (if more than one) assure the same packet quality. While one document 
[TR45: Interoperability Specification (lOS) for cdma200 Access Network Interfaces - Part 2 
Transport", PN-4545.2-RV3, Ballot Version October 2002] broadly states that radio access 
network policies or local policies defined by service providers can be used by the RN and the 
PDSN to mark and condition the uplink and downlink traffic, it does not define a mechanism 
to do so. The prior art particularly describes the mapping of only downlink packets to a 
service instance in order to assure a quality of service in the mobile network, and does not 
appear to enable flows of different packet quality on the same service instance. . What is 
needed in the art is a way to implement quality of service in a DiffServ architecture at the R-P 
interface to assure quality on both uplink and dovralink traffic, preferably a quality that may 
differ among flows on the same service instance. 

STJ3VIMARY OF THE INVENTION: 

[0007] This invention is in one aspect a method for establishing a flow within a 

connection. The method includes receiving at a wireless network node a first request 
message. This first request message includes at least one quality parameter for the flow. 
Further, the method includes granting a plurality of quality of service parameters. The method 
continues in sending from the wireless network node a second request message that includes 
one or more granted quality of service parameters, which may be the same as the at least one 
quality parameter used in the first request message. Prefereably, the wireless network node is 
a radio node and the connection is between the wireless network node and a further node such 
as a PDSN. 

[0008] In another aspect, the present invention is a signaling protocol that may be used 

to enable an assured quality on a flow between a radio node and a packet switching data node. 
The radio node receives from the mobile station a request that includes at least one quality of 
service parameter for the flow. Subsequently, the radio node sends to the mobile station a 
^ grant of a set of quality of service parameters for the flow. The radio node ftirther sends a 
registration request to the packet data switching node that includes the granted set of quality of 
service parameters for the flow. Then, the radio node receives from the packet data switching 
node a registration reply that authorizes the flow. 
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[00 1 0] In yet another aspect, the present invention is a wireless network node, such as 

a wireless base station, that has a receiver, a controller, and a transmitter. The receiver is for 
receiving a QoS parameter request message that includes at least one quality of service 
parameter for a flow within a connection. The controller is coupled to the receiver, and is for 
determining whether a subject connection, on which a flow satisfying the set of at least one 
quality parameters between at least a base station and a mobile station is to be carried, is a pre- 
existing comiection or a new connection. The transmitter is coupled to the controller for 
sending, in response to the controller determining as above, a service connect grant message 
to the mobile station. 

[0012] These and other features, aspects, and advantages of embodiments of the 

present invention will become apparent with reference to the following description in 
conjunction with the accompanying drawings. It is to be understood, however, that the 
drawings are designed solely for the purposes of illustration and not as a definition of the 
limits of the invention. 

Brief Description of the Drawings: 

[001 3] The present invention is described below more particularly with reference to 

the following drawing figures, which are not to scale except where stipulated. 
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[0014] Figure 1 is a prior art overview of packets moving between a mobile station 

aad an extemal network via a radio node RN and a packet data switching node PDSN. 

[0015] Figure 2, divided among two sheets as Figures 2 A and 2B, is a signaling 

diagram between nodes of the network of Figure 1 that enables QoS DifiEServ in both uplink 
and downlink directions at initial setup of a service instance. 

[0016] Figure 3 is similar to Figure 2 but showing signaling to modify QoS in an 

existing service instance. 

[0017] Figure 4A is a signaling diagram showing specific treatment of downlink 

traffic in a first alternative embodiment. 

[0018] Figure4B is a signaling diagram showing specific treatment ofuplink traffic in 

the first alternative embodiment 

[0019] Figure 5A is a signaling diagram showing specific treatment of downlink 

traffic in a second alternative embodiment. 

[0020] Figure 5B is a signaling diagram showing specific treatment ofuplink traffic in 

the second alternative embodiment. 

[002 1 ] Figure 6 is a signaling diagram showing specific treatment ofuplink traffic in a 

third alternative embodiment. 

[0022] Figure 7A is a perspective view, and Figure 7B is a block diagram schematic, 

of a mobile station configured according to the present invention. 

Detailed Description: 

[0023] Further to the background description above, the prior art does not appear 

capable of determining which flow a packet should be transported when more than one flow 
exists on a service instance, and does not provide a mechanism for the PDSN 30 to obtain the 
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QoS requirement of different flows inside an auxiliary service instance. Rather flian merely 
add service instances for each flow, the present invention seeks to enable multiple flows 
within each (preferably auxiliary) service instance to result in less R-P connections and better 
use of available bandwidth (due to less signaling to set up and maintain excess R-P 
connections) in the mobile network 22. In order to provide the DiffServ based QoS at the R-P 
interface, the DififServ functionality for the edge routers (e.g., packet classification, marking, 
metering, pohcing and shaping) should be implemented in the RN 24 and the PDSN 30. In 
order to perform these functions, the present invention provides a signaling mechanism so that 
all the Quality of Service (QoS) related information is relayed aiid/or configured at the RN 24 
and the PDSN 30. 

[0024] The present invention presents an improved method and system for enabling 

trafiSc flow management between ingress and egress nodes of a DiffServ network, with 
several variances for uplink and downlink traffic. Each approach has the mobile node or 
station MS 26 providing QoS requirements to the RN 24 and PDSN 30 to assure a quality for 
packets within a flow. Preferably, in each separate embodiment described, QoS requirements 
are signaled at the link level using a known format such as "QoS_BLOB" (as defined in 
TIA/IS-707-A-3), or at the IP level via an extended dynamic flow mapping mechanism. Also 
described are specific details as to how such QoS information is used at the RN 24 and the 
PDSN 30 to provide QoS support to the R-P interface and extemal network 32. 

[0025] While the use and implementation of particular embodiments of the present 

invention are presented in detail below, it will be understood that the present invention 
provides many inventive concepts that can be embodied in a wide variety of contexts. The 
specific embodiments discussed hereia serve as non-limiting illustrations for making and 
using the present invention, and are not intended to limit its scope or the ensuing claims. 

[0026] Figure 2 provides a signaling regimen between the MS 26, the RN 24, and the 

PDSN 30, with some peripheral signaling between the PDSN 30 and an Authentication, 
Authorization and Accounting node (AAA) 36. The AAA 36 is generally a separate server 
that provides authorization for a IMS 26 to operate within its home network or cooperating 
foreign networks, such as when the MS is moving out of its home network area, when a 
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particular auxiliary service instance must be routed through a foreign network, and the like. 
The AAA 36 serves to authenticate a particular MS 26, authorizes it to use some or all 
services of the home network or foreign networks with which the home network has a service 
level agreement SLA, and to track accessed services and other metrics used to calculate 
payments according to the SLA or user agreement. Figure 2 (which includes continuous 
Figures 2A and 2B) represents the preferred enibodiment of the present invention. 

[0027] Initially, the MS 26 and the PDSN 30 setup 38 a main service instance as 

known in the art. This may be initialized by the MS 26 in the case of initiating uplink traffic 
28, or by the PDSN 30 through the base station BS 24 in the case of initiating downlink traffic 
34. The PDSN 30 submits an access request 40 to the AAA 36 concerning the particular MS 
26. The AAA 36 authenticates the particular MS 26, and if authorized, provides an 
acceptance message 42 to the PDSN 30 that includes a subscriber profile of the MS 26. The 
subscriber profile may include quality of service parameters associated with the MS user: for 
example, the MS user may be a premium or gold user whose network service contract assures 
a minimum reliability for file transfers, authorizes reception of digital video broadcast (DVB- 
H) at an assured quality, and the like for different types of data. Quality among the different 
types of data is generally reflected as QoS parameters such as but not limited to bandwidtii 
(bits per second), maximum packet delay (milliseconds), and acceptable packet loss rate (%). 
QoS parameters within the QoS user/subscriber profile are subject to change and evolution 
with increasing refinements to DififServ and packet transport quality, and may be variable 
dependant upon activity in the mobile network 22, time of day (e.g., user profile provides one 
QoS that is valid between 7am and 7 pm, and a higher QoS that is valid at other times), etc., 
all without departing from the present invention. 

[0028] Sometime after the main service instance is established 38, the MS 26 becomes 

aware of a dataflow for which a specific QoS parameter is relevant or desired. For example, 
the MS 26 may prepare to transmit a digital photograph attached to an email text, or may 
prepare to receive a digital video broadcast. Alternatively, the MS 26 may be moving between 
radio access networks. In either case, the MS 26 creates a flow and an identifier for each flow 
that it desires to be established in order to send the relevant data (e.g., one flow for packets of 
the digital photo, another for packets of the email text, etc.). Term this MS_FLOW_ID, 
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recognizing that a flow is a series of packets tiiat share a specific instantiation of (IETF) 
protocol layers. The MS 26 transmits to the RN 24 a QoS parameter request message 44, 
which includes at least those QoS parameters relevant to the MS-created dataflow and the 
identifier for the new flow, MS_FLOW_ID. Preferably, these parameters are in the 
QoS_BLOB format defined in the prior art. Li the example of Figure 2, the QoS parameter 
message 44 includes a service instance identifier (SR_ID x) that uniquely identifies a new R-P 
connection to be set up that carries the flow MS_FLOW_ID created by the MS 26. Assume 
for example that the requested parameter is a mmimum bandwidth of wi bits per second for the 
flow MS_FLOW_ID. It is notable that the QoS parameter of the message 44 is a request, and 
that the parameter is associated within a single message with a specific service instance 
identifier (SR_ID x) and a specific flow identifier (MS_FLOW_ID) that was created by the 
MS 26. 

[0029] Following receipt of the requested QoS parameter(s), the RN 24 performs 

admission conlxol 46. In admission control 46, the RN 46 determines whether the mobile 
network 22 can fiilfiU the quality indicated in the QoS request message 44, for example, via 
the home or a foreign network. Two options are shown: a new service instance (SR_ID x) is 
set up at messages 48-50, and an existing service instance (SR_ID y) is reconfigured at 
messages 48 '-50'. 

[0030] In the first option, admission control 46 at the RN 24 determines that network 

facilities are available to meet the requested QoS parameter (e.g., of m bps minimum 
bandwidth), and a new service instance, identified as SR_ID x, is set up as follows. This 
option may occur where the main service instance that was set up at reference number 38, or 
any other existing service instances for that MS 26, cannot be adapted to the QoS parameter of 
the MS-created new flow. The RN 24 sends a service connect message 48 to the MS 26 that 
includes the identifier for the existing service instance (SR_rD x), a grant of the QoS 
parameter (e.g., minimum x bps bandwidth), and connection parameters for the airlink for the 
traffic between the MS 26 and the base station 24. This message 48 should also include the 
flow identifier created by the MS 26 to which the QoS grant appUes, which in Figure 2 is 
inherent in the QoS_BLOB format. 
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[0031] Where a new connection is required to be established (e.g., an AlO 

connection), the KN 24 coordinates with the PDSN 30 in a registration request message 52, 
which may be in parallel with or following the service connect message 48 and service 
connect completion message 50. For ready adoption within existing infrastructure, preferably 
the registration request message 52 is of the Al 1 message format. However, the present 
invention includes both the service instance identifier (e.g., SR_ID x) and at least one 
(preferably both) of the requested and granted QoS parameter(s) that were previously 
exchanged between the MS 26 and the RN 24 at messages 44 and 48, as well as the flow 
identifier to which the QoS parameter relates. The PDSN 30 authorizes 54 the new service 
instance (SR^K) x) which meets the QoS parameter of the registration request 52. This grants 
the QoS parameter request, because the flow created by the MS 26 (identified as 
MS_FLOW_ID) is within that new service instance. Once authorized 54, the PDSN 30 sends 
a registration reply message 56 to the RN 24 informing it that the new service instance 
(SR_1D x) is established that meets the requested QoS parameter. 

[0032] In the second option, the RN 24 decides at admission control 46 to carry the 

flow on an existing service instance (SR_ID y). Assume for this example that the existing 
service instance is an auxiliary service instance that enables a maximum packet delay of y 
milliseconds, where the requested QoS parameter is minimum bandwidth ofx bps. The RN 
24 reconfigures the parameters of the existing service instance (SR_1D y) to those of the 
request (e.g., x bps bandwidth), and sends a service connect message 48' to the MS 26 that 
includes the applicable service instance identifier (e.g., SR_ID y), a grant of the x bps 
bandwidth, and connection parameters for the airlink for the traffic between the MS 26 and 
the base station 24. As above, the flow identifier created by the MS 26 is also within this 
message 48 ' . hi either option described by messages 48-50 and 48'-50' and above, the MS 26 
replies with a service connect completion message 50, 50' to set up the traffic channel airlink. 

[0033] Where a new connection is not required and an existing connection is 

reconfigured, signaling is similar to that described above for a new connection with the 
following exceptions. The registration request 52 fi:om the RN 24 to the PDSN 30 includes 
the service instance identifier (e.g., SR_ID y) and the modified granted QoS parameter(s).that 
were previously sent to the MS 26 at message 48', as well as the flow identifier to which the 
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QoS parameter relates. The PDSN 30 authorizes 54 the existing service instance (SR_ID y) to 
meet the QoS parameter(s) of the registration request 52. Once authorized 54, the PDSN 30 
sends a registration reply message 56 to the RN 24 informing it that the existing service 
instance (SR_ID y) is modified to meet the requested (and now granted) QoS parameter. 

[0034] To complete the signaling before packets are sent on the uplink 28 or downlink 

34 along the new flow, the MS 26 sends a reservation RESV message 58 that carries the flow 
identification (MS_FLOW_rD), the direction of the flow (uplink 28 or downlink 34), and the 
filter parameters for the auxiliary service instance. The RESV message 58 may be generically 
termed a filter message, as it carries information conceming filtering packets. In the prior art, 
the packet filter parameters are generally in a transport flow template TFT format, an 
embodiment that may continue with the present invention for ready adoption by the affected 
networks, though the format alone is not limiting. This RESV message 5 8, which may be on 
ttiis main service instance estabUshed at the main service instance setup 3 8 or on an auxiliary 
service instance of the new flow, informs the PDSN 30 which packets are to go into which 
flow, and consequently how the packets will move through the internal nodes of the external 
(IP-based) network 32. For example, if two flows are set up (either within one or two service 
instances), one for still photos and one for voice over IP, the RESV message 58 identifies 
which differentiated services code point (DSCP), which is in the packet header, goes into 
which flow. The single TFT may inform as to multiple flows and multiple filters where more 
than one flow is active for the subject MS 26. The PDSN 30 replies with a RESV 
confirmation message 60. The end result is that flie PDSN 30 has information to map each 
packet to a specific flow using only bits of the packet headers. 

[0035] For example, assimie as above that two flows are set up: one for a still photo 

and one for VoIP. The DSCP is sbc bits, so the MS 24 informs the PDSN 30 in the RESV 
message 58 that a packet with the value 01 1 101 in the DSCP header should go into a first 
flow. That the first flow is associated only with one service instance is inherent wifliin the 
service instance/flow framework. It is unnecessary that the PDSN 30 be aware that packets 
bearing.that specific DSCP relate to a still photo; only the map is necessary in the PDSN 30 
and the MS 26 determines the appropriate QoS parameter for the underlying data type in 
creating the flow. That same RESV message 58 informs that packets with DSCP header value 
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of 01 1 1 10 go into a second flow, which may or may not be over the first service instance. 
Each of these flows has a different QoS due to the different nature of the underlying data: 
packets iBrom the photo are somewhat delay insensitive but the resultant photo may be 
noticeably corrupted by packet loss, whereas VoIP packets are delay sensitive but relatively 
packet loss insensitive. The different QoS parameters used to set up the data flows reflect the 
underlying data type, but the data flows are created in the MS 26 and not in the RN 24 or the 
PDSN 30. The RESV message 58 informs the PDSN 30 which packets go into which data 
flow, and the PDSN 30 builds a map of DSCP to data flo^y. While the MS may transmit a 
photo packet that is sequentially disposed between two VoIP packets, the PDSN 30 separates 
them with knowledge only of the DSCP in the header. Nodes internal to the CDMA2000 
network 32 that further transmit the packets need not open the headers or even be aware of the 
map, because they are operating on a Integrated Services IntServ model where the flow 
through the network is predetermined upon the packet's entry into the edge of that network. 
Those internal nodes merely relay without knowledge of QoS, potential altemative flows, 
underlying data type, or the like. That the relay internal to the CDMA2000 network 32 
satisfies the quality of service requested by the MS 26 (and granted by the PDSN 30 and RN 
24), and not merely reflect a best effort attempt to move the packet along, is accomplished in 
DifEServ by the efficient signaling of the present invention. 

[0036] Figure 3 is a signaling diagram similar to that of Figure 2, but in the context of 

an already-established service instance to which a QoS parameter is updated by the RN 24. 
That context is reflected as an ongoing flow 62(over any service instance) between the MS 26 
and the PDSN 30 via the RN 24 or base station BS, and may occur when the RN/BS 24 
desires to modify the ongoing flow 62 due to changing traffic or radio conditions. The RN 24 
chooses which QoS parameter to update 64 for a particular flow, and sends a registration 
request message 52' to the PDSN 30, carrying the relevant service instance (SR_ID), flow 
(MS_FLOW_ID), and the updated QoS parameter(s) for that connection and flow. The PDSN 
30 authorizes the updated QoS parameter(s) 54', and sends a registration reply 56' back to the 
RN 24 granting the updated QoS parameter(s). Upon successful authorization, the RN 24 
sends to the MS 26 a service connect message 48", which in the context of Figure 3.includes 
the service instance identifier (SR_ID), the flow identifier (MS_FLOW_ID), the updated and 
granted QoS parameter(s), and any relevant airlink parameters if the airlink itself is also 
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changed. The MS 26 replies with a service connect completion message 50" . Where the 
QoS parameter of a specific flow is being upgraded (e.g., minimum bandwidth changed firom 
X bps to 2x bps), the messages 48" and 50" must follow messages 52* and 56'; otherwise, 
they may occur in parallel. 

[0037] Where a flow is no longer needed, the MS 26 makes the determination itself 

and signals the RN 24 identifying the flow to be removed, the service instance in which it lies, 
and its associated QoS parameter. The RN 24 sends a registration request to the PDSN 30 
including the QoS parameters received from the MS 26, the flow identifier and the service 
instance. If no other flows are carried on the relevant service instance, the RN 24 may also 
request disconnection of that service instance in the registration request message. The PDSN 
30 deletes the packet filters for that flow and sends a registration reply message to the RN 24. 
The RN 24 then sends a service connect message to the MS 26 to indicate that the flow is 
removed, and if no other flows are carried on that service instant and the entire service instant 
is disconnected, then the RN 24 also disconnects the service instance in the service connect 
message. The MS 26 replies to the RN 24 with a service connect completion message. 

[0038] The essence of Figure 2 is that the RN 24 obtains or derives the QoS 

requirement fi:om the MS 26 and then sends the QoS requirement to the PDSN 30. Separate 
treatment of downlink and uplink traffic using this information, according to a first alternative 
embodiment, is shown in Figure 4A (downlink) and Figure 4B (uplink). A second alternative 
embodiment for separate treatment of uplink and downlink traffic is shown in Figures 5 A 
(downlink) and Figure 5B (uplink). A third alternative embodiment for uplink traffic is 
shown in Figure 6. Each of these is supplementary to the signaling of Figure 2, and show 
uplink and downlink enforcement of policies decided at the PDSN 30 or the RN 24. Where 
shown also in the alternative embodiments, messages described in Figure 2 are modified in 
the alternative embodiments, made apparent by the message titles, message contents, and/or 
the accompanying explanatory text. 

[0039] On the downlink of Figure 4A, the RN 24 sends a registration request 66 to the 

PDSN 30, but in this first alternative embodiment, the message 66 includes the service 
instance identifier and the QoS_BLOB message (which includes the QoS parameters). The 
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PDSN 30 decides 68, based onflie request message 66, on aDiflGServpolicy (examples below) 
for the downliiik traffic 34, and thereby build a map between the service instance and the 
DiffServ policy that is used to map downlink packets 34 to the proper service instance and 
flow. The PDSN 30 then sends a registration reply message 56 after authorization, and the 
RN 24 sends a service connect message 50, 50' as previously described. The MS 26 then 
sends a filter or RESV message 70 that is similar to the RESV message 58 previously 
described, but in this instance it need not include the flow identifier, as that is already 
provided to the PDSN 30 in the QoS_BLOB portion of the registration request message 66. 
Instead, this filter message 70 includes the service instance identifier and the TFT (with filter 
parameters for the flow) for downlink traffic. The PDSN 30 uses this additional information 
on the filters to map the DiflfServ policy to the flows (using the packet filters) via the service 
instance identifier. 

[0040] DiffServ policies may include, but are not limited to, DSCP marking as 

previously noted, and/or traffic policing^shaping policies, and may also take into account the 
subscription profile 42 described in Figure 2. The definition of these policies'may vary among 
different mobile network 22 operators, though two different examples are given. As an 
example of a DiffServ marking policy, assume a downlink packet having QoS parameters of 
a) requested bandwidth ofx bps, b) requested maximum delay ofy ms, and c) acceptable loss 
rate of z%, are to be marked with a DSCP value of 011001. Other QoS parameter 
combinations and thresholds equate to a different DSCP value. As an example of a DiffServ 
marking traffic policing/shaping policy, assume a streaming application (which may be 
specified by a traffic class or an appUcation ID) used by a high priority user (e.g., a user 
paying a premium for enhanced service) should not exceedXbps during certain hours, such as 
those in which the mobile network 22 traditionally carries heavier traffic. Such a DiffServ 
marking traffic policing/shaping policy could be specified in the specific user QoS profile, or 
may be defined by the local mobile network 22 for its specific limitations. Although the RN 
24 may be aware of those policies, instead of overloading the RN 24 - MS 26 iriterface by 
enforcing them at that juncture (which is traditionally the most bandwidth-limited), the PDSN 
30 can enforce the policies for downlink traffic 34 by dropping or shaping the out-of-profile 
packets based on such a policy before they reach the RN 24. As downlink traffic passes the 
PDSN 30, the PDSN 30 maps the packets into the correct service instance based on the TFT, 
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and marks the packet with the correct DSCP associated with the SR_ID. Other possible 
DiffServ functions (e.g., poUcing, shaping) can be performed as well, as noted above. 

[004 1 ] On the uplink as shown in Figure 4B for this fibrst alternative embodiment, the 

QoS parameter(s) and the flow identifier is directly mapped to DSCP and other DiffServ 
policies. After obtaining that information jfrom the MS 26, the RN 24 decides 74 which 
DiffServ policies (e.g., DSCP marking) are to be applied to the service instance, then 
establishes the mapping between SR__ID and DiffServ poUcy. The registration request 76 
need only include the service instance identifier, as the mapping for this uplink 28 flow is at 
theRN24. 

[0042] A second alternative is depicted at Figures 5A (downlink) and Figure 5B 

(uplink). In Figure 5 A, the MS 26 sends downlink QoS requirements to the PDSN 30, along 
with the TFT which carries the downlink flow filters, in ttie RESV message 78. The QoS 
requirement carried in the RESV message includes the same information as noted above, or 
may include a new infomiation element or the FLOWSPEC format defined for DiffServ. 
After receiving the RESV message 78, the PDSN 30 decides 80 a DiffServ policy to be 
applied, based on the QoS requirement for the downlink traffic, and creates the mapping 
between the flow (via the filters of the TFT), the service instance which carries the flow 
(SR_ID) and any relevant DiffServ policy such as those in the examples above. The 
registration request 76 need only include the service instance identifier, and ttie registration 
reply 56 and RESV or filter confirmation 60 messages are as previously described. 

[0043] For the uplink in this second alternative embodiment as shown in Figure 5B, 

the MS 26 sends a RESV message 82 to the PDSN 30, which includes the service instance 
identifier, uplink and downlink QoS parameters, and filter parameters for the downlink (TFT). 
The PDSN 30 uses that information to decide 84 on a DiffServ policy for the uplink traffic 
and builds a map between the service instance and the DiffServ policy. The PDSN 30 then 
signals 86 the RN 24 to execute the uplink traffic handling policy decided by the PDSN 30. 
Preferably, this message 86 devolving enforcement of the policy is in the known COPS 
format, and carries the service instance identifier and the decided policy that is to be applied to 
uplink traffic on that service instance. Altematively, the message 86 may be a modified Al 1 
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message. Since the RN 24 already knows the flow created by the MS 26 (from message 44 of 
Figure 2), the service instance identified in the message 86 is used to uniquely identify to the 
RN 24 the relevant flow of that service instance to which the DifiBerv policy is to be 
enforced. An acknowledgment message 88 of some fonn is sent to the PDSN 30, and the 
PDSN 30 then sends a confirmation message 60 to the MS 26. 

[0044] Figure 6 shows a third alternative embodiment for the specific treatment of 

uplink 28 traffic. The MS 26 sends a RESV or filter message 90 which carries the service 
instance identifier, the uplink QoS parameter(s), and the downlink filter parameters (TFT). 
The RN 24 receives that RESV message 90. In this embodiment, besides forwarding 90' that 
message 90 to the PDSN 30, the RN 24 intercepts 92 the RESV message 90', decides on a 
DiffServ policy for uplink traffic, and maps the service instance identifier to the DiffServ 
policy. The PDSN 30 ignores 94 the uplink QoS parameter(s) because in this embodiment, 
the RN 24 enforces the DiffServ policy for the uplink traffic. The PDSN 30 sends a 
confirmation message 60 to the MS 26 as previously described. 

[0045] Although the solutions for uplink and downlink traffic are diagrammed 

separately, the correspondent solutions can be merged together, including mixing uplink and 
downlink solutions for the different preferred and alternative embodiments. 

[0046] The mobile station 26 described in the above signaling interchange is now 

described with reference to Figures 7A and 7B. Certain of the electronics described in the 
block diagram of Figure 7B are also within the above-described base station 24 and PDSN 30. 
The mobile station 26 may be, but is not limited to, a cellular telephone or a personal 
communicator. The mobile station 26 includes one or more antennas 102 for transmitting 
signals to and for receiving signals firom a mobile node or base station 24. The base station 24 
may be a part of a network comprising a PDSN 30 and a mobile switching center (MSG, not 
shown). The MSG provides a connection to landline trunks when the mobile station 26 is 
involved in a call. The mobile station 26 mcludes a modulator (MOD) 104A, a transmitter 
104, a receiver 106, a demodulator (DEMOD) 106 A, and a controller 108 that provides 
signals to and receives signals firom the transmitter 104 and receiver 106, respectively. These 
signals include signaling information in accordance with the air interface standard of the 
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applicable cellular system, user speech and/or user generated data, and the signals described 
above with particularity. While the teachings of this invention can be readily applied to GSM- 
type TDMA mobile stations, they could be applied as well to code division/multiple access 
(CDMA) and other type of systems. 

[0047] It is understood that the controller 108 also includes the circuitry required for 

implementing the audio (speech path) and logic functions of the mobile station. By example, 
ttie controller 108 may be comprised of a digital signal processor device, a microprocessor 
device, and various analog to digital converters, digital to analog converters, and other support 
circuits. The control and signal processing functions of the mobile station 26 are allocated 
between these devices according to their respective capabilities. 

[0048] A user interface includes a conventional earphone or speaker 110, a 

conventional microphone 1 12, a display 1 14, and a user input device, typically a keypad 1 16, 
all of which are coupled to the controller 108. The user input device may also include a 
digital still or video camera. The keypad 116 includes the conventional numeric (0-9) and 
related keys (#,*) 1 1 6a, and other keys 1 1 6b used for operating the mobile station 26. These 
other keys 1 1 6b may include, by example, a SEND key, various menu scrolling and soft keys, 
and a power on/off key. These keys may also be co-located with the display 1 14 as a touch 
sensitive screen, their function may be actuated by voice-recognition via the speaker 1 12, or 
otherwise differently embodied to perform the same or expanded functionality as is known for 
traditional 1 1 6a and other 1 1 6b keys. The mobile station 26 also includes a removable battery 
1 18 for powering the various circuits that are required to operate the mobile station 26. 

[0049] The mobile station 26 also includes various memories, shown collectively as 

the memory 1 20, wherein are stored a plurality of constants and variables that are used by the 
controller 108 during the operation of the mobile station. For example, the memory 120 
stores the values of wireless system parameters, a unique identifier for the mobile station 26, 
an operating program for controlling the operation of the controller 108 (each typically in a 
ROM device), and various software application programs for running specific applications 
within the context of the operating program (the application programs being typically in a 
read/write. RAM device). The operating program in the memory 120 includes routines to 
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present messages and message-related functions to the user on the display 114, typically as 
various menu items. 



[0050] In accordance with the present invention, an application software program 122, 

which may be a stand alone program or one that additionally modifies other pre-existing 
programs (such as to construct a message 44 with certain data not otherwise present), is stored 
in the memory 120 that maps data type to at least one quality parameter. The mobile station 
26 determines an underlying data type for an uplink or downlink packet, uses the application 
program 1 22 to determine which quality parameter(s) to apply to that data type, and sends the 
QoS parameter request message 44 as described above. This QoS parameter request message 
44 is novel in that it includes both the QoS parameters from the software application map and 
the service instance identifier, and preferably also the flow (created in the MS) to which the 
QoS parameter(s) are to apply. Further, the application program causes the MS 26 to send, in 
response to (i.e., automatically) receiving the service connect message 48, 48', the RESV or 
filter message 58, 70, 78, 82, 90 that carries the QoS parameter(s) and the service instance 
identifier, and preferably also the flow direction and the flow identifier that is created for the 
flow in the MS 26. 

[005 1] Most of the above circuitry of Figure 7B is also present in the RN 24 and the 

PDSN 30, typically excepting the microphone 1 12, battery 118, speaker 1 10, display 1 14 and 
keypad 1 16. The RN 24 and the PDSN 30 each have an application software program to 
construct the messages detailed above that are transmitted from those respective nodes, certain 
of them in response to receiving other messages from either the MS 26, MN 24, or the PDSN 
. 30 as particularly detailed in the preferred and altemative embodiments above. 

[005 2] While there has been illustrated and described what is at present considered to 

be preferred and altemative embodiments of the claimed invention, it will be appreciated that 
numerous changes and modifications are likely to occur to those skilled in the art. It is 
intended in the appended claims to cover all those changes and modifications that fall wifliin 
the spirit and scope of the claimed invention. 



PCT/US04/25398 

Art 34 Amendment dated Feb. 16. 2005 
Replacement Page 



19 



( 



( 



Claims: 

WHAT IS CLAIMED IS: 

1 . A method for establishing a flow comprising: 

receiving at a wireless network node a first request message, said first request 
message-comprising at least one quality of service parameter for the flow; 
granting a plurality of quality of service parameters; 

sending from the wireless network node a second request message, the second 
request message comprising one or more granted quality of service parameters. 

2. The method of claim 1 wherein the wireless network node is a radio node. 

3 . The method of claim 1 , further comprising: 

sending from the wireless network node to a mobile station a reply message, said 
reply message including the granted plurality of quality of service parameters and airlink 
parameters for the flow. 

4. The method of claim 3, wherein said reply message further includes a flow 
identifier. 

5 . The method of claim 2 further comprising receiving from a node other than the 
wireless network node and a mobile station that originates the first request message, and 
prior to the sending of the first request message, a subscriber profile that includes a series 
of quality parameters associated with the mobile station. 

6. The method of claim 2, farther comprising: 

sending from a mobile station that originates the first request message to a fiirther 
node a filter message, said filter message including at least one packet filter. 

7. The method of claim 6, wherein the at least one packet filter comprises a plurality 
of packet filter content options, and the at least one packet filter is identified by a flow 
identifier. 
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8. The method of claim 2 further comprising: 

detemiining at the wireless network node that the flow caimot be further supported 
to meet the plurality of quality of service parameters that were granted; 

sending a modified second request message that includes at least one updated 
quality of service parameter; and 

receiving authorization to satisfy the at least one updated quality of service 
parameter. 

9. The method of claim 8, wherein the modified second request message includes an 
identifier for the flow. 

10. The method of claim 1 further comprising: 

determining a policy to apply to a packet transported on the flow, and mapping an 
identilBer associated with the flow to the policy. 

1 1 . The method of claim 10, wherein determining a policy is at a further node, the 
method furttier comprising enforcing the policy at the furflier node on the packet sent in at 
least one of an uplink and a dovralink direction. 

12. The method of claim 10 wherein determining a policy is at the wireless network 
node, the method further comprising enforcing the poUcy at the wireless network node for 
the packet sent at least in an uplink direction from the first to the further node. 

1 3 . The method of claim 1 0 wherein determining a policy is at the further node, the 
method further comprising enforcing the policy at the wireless network node at least for 
the packet sent in an upliiik direction from the wireless network node to the further node. 

14. (Canceled) 

15. A signaling protocol to enable an assured quality on a flow comprising: 

a radio node receiving from a mobile station a request that includes at least one 
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quality of service parameter for the flow; 

the radio node sending to the mobile station a grant of a set of quality of service 
parameters for the flow; 

the radio node further sending a registration request to a packet data switching 
node that includes the granted set of quality of service parameters for the flow; and. 

the radio node receiving from the packet data switching node a registration reply 
that authorizes the flow. 

16. The signaling protocol of claim 28 further comprising the mobile station sending a 
filter message to the packet data switching node that comprises at least one packet filter for 
the flow. 

17. The signaling protocol of claim 28 further comprising receiving at the packet 
switching data node from an AAA node a series of quality of service parameters associated 
with the mobile station. 

1 8. The signaling protocol of claim 1 5, wherein the grant comprises, in a single 
message, an identifier for the flow. 

1 9. The signaling protocol of claim 1 5 wherein the request comprises, in a single 
message, an identifier for the flow and the at least one quality of service parameter. 

20-22. (Canceled) 

23, A wireless network node comprising: 

a receiver for receiving a QoS parameter request message that includes at least one 
quality of service parameter for a flow; 

a controller coupled to the receiver for determining and granting at least one quality 
of service parameters; and 

a transmitter coupled to the controller for sending, in response to the controller 
determining and granting, a reply message to the mobile station. 
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24. The wireless network node of claim 30, wherein the registration request message 
further comprises the at least one quality of service parameter. 



25-26. (Canceled) 

27. The method of claim 2 wherein the further node is a packet data switching node. 

28. The signaling protocol of claim 1 5, further comprising: 

the mobile station signaling the packet data switching node via the radio node with 
packet filters that identify the flow. 

29. The wireless network node of claim 23, wherein the transmitter is further for 
sending a registration request message to a packet data switching node. 

30. The wireless network node of claim 29, wherein the registration request message 
comprises an identifier for the flow. 
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